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Remarks/ Arguments 

Claims 1-14 are pending. The claims have been amended to correct 
obvious defects, and as such are not believed to raise, new issues of 
patentability. No new matter is believed to be added by the present amendment. 

Rejection of claims 1-4, 7-10 and 12-14 under 35 USC §1 02(b) as being 
anticipated by Tai, T., Gerla, M., "LAN interconnection; a transparent, short- 
path approach 11 IEEE International Conference on Communications, 23-26, 
June 1991, pages 1666-1670, vol. 3 (hereinafter, "Tai") 

Applicants submit that Tai fails to disclose each and every limitation 
recited in the subject claims, and thus, present claims 1-4, 7-10 and 12-14 are 
not anticipated under 35 U.S.C. §1 02(b) by Tai as alleged by the Examiner. 

The examiner's response states n [a]s shown in Fig. 1 on page 1667 is the 
forwarding database of a specific port is a brouter and which is implemented at 
each port of the brouter ... Thus, Tai is building a forwarding database (routing 
table) by using the Bellman-Ford Algorithm." The examiner further states that 
according to Tai the forwarding database at each port is constructed by 
exchanging the delay tables periodically among the brouters attached to the 
same LAN. However, applicants submit that even assuming arguendo that Tai 
teaches generating a forwarding database through periodic exchange of delay 
tables as alleged, Tai still fails to disclose or suggest all of the limitations of the 
present claims. 

The present invention involves a method for building a routing table by 
performing an iterative process that includes exchanging routing table data 
between two portals of a bridge, concatenating received routing table data with 
the routing table data of a given portal, exchanging the routing table data 
between the portals connected to the same bus, and concatenating the received 
routing table data with routing table data of the given portal. In that regard, claim 
1 recites: 
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(a) transmitting, by a given portal, routing table data stored by 
said given portal to a companion portal associated with said given portal 
and receiving, by said given portal, routing table data from the companion 
portal; 

(b) concatenating said routing table data received in step (a) 
with the contents of the routing table data stored by said given portal; 

(c) broadcasting said routing table data stored by said given 
portal on a local bus associated with the given portal; 

(d) receiving routing table data broadcast by other portals on 
the local bus and concatenating said received routing table data broadcast 
by other portals with contents of the routing table data stored by said given 
portal; 

(e) repeating the above steps until routing data concerning all 
buses in the network has been received by said given portal. 

By contrast, the method of Tai for building a routing table involves the 
steps of building a delay table at each brouter, exchanging these delay tables 
between the brouters, and computing a routing table at each port based on the 
delay tables. Tai also addresses the different problem of determining a unique 
LAN id for each LAN, and building a mapping table between all station ids and 
their LAN id. 

More specifically, Tai teaches "... The construction of the forwarding 
database is essentially a background process in the brouter, which will be 
discussed in section 2.2. Furthermore, the manipulation of station and LAN 
identifications as well as the migration of stations will be presented in section 3." 

Paragraph 2.2 states in part, "more specifically, at brouter b, say, the 
tables Delay b (i) and OutPort b (i) are kept ..." and gives the algorithm to compute 
these tables : Delay b (i) = min b {Delay b (i) + l(b, b')}. After computing the tables, 
each brouter b host its own Delay b (i) table. Then, an exchange of the Delay 
table occurs between brouters, e.g., "... the forwarding database at each port is 
constructed by exchanging the delay tables periodically ..." Once these delay 
tables have been received, the forwarding database is computed using the 
specified algorithm, e.g., "[a]fter receiving the delay tables, each port p, say, of 
brouter b calculates its own forwarding database indexed by destination LAN id 
as follows ..." 
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In view of the above, Applicants submit that the limitations recited in the 
present claims for determining the routing tables clearly are not disclosed or 
suggested by the steps described by Tai for computing the routing tables. 

Claim 1 recites "... transmitting by a given portal, routing table data stored 
by said given portal to a companion portal associated with said given portal and 
receiving, by said given portal, routing table data from the companion portal." 
This limitation relates to an exchange of routing table data at the level of each 
bridge, particularly, between the different routing tables located at each 
portal of the particular bridge. Contrary to the Examiner's assertion, this 
limitation is not taught by Tai. 

The Examiner asserts that page 1667 of Tai discloses this limitation (see 
6-28-05 Office Action, page 6). However, the portion of Tai cited by the 
Examiner (§3.2) concerns an algorithm to build a mapping table and a scheme to 
broadcast a list of local stations on a LAN (obtained by intersecting the lists of 
station ids on all the ports which are directly connected to that LAN (inter- 
bridge)). Tai is not concerned with the exchange of routing table data at the level 
of each bridge between the different tables located at each portal of the particular 
bridge per claim 1 . Applied to the context of Tai, this limitation of claim 1 would 
require an exchange in the brouter between routing tables maintained at the 
port level of the brouter. However, Tai clearly does not teach the exchange of 
data within the brouter, instead, Tai teaches the exchange of data between 
ports of different brouters on a connected LAN. 

Tai clearly does not teach exchanging routing table data between ports of 
the same bridge (brouter) as recited in step (a) of independent claim 1 , but rather 
teaches exchanging routing table data between ports of different brouters 
(bridges) that are connected on a LAN. Therefore, applicants submit that Tai 
fails to disclose or suggest the above-mentioned limitation of claim 1 . 

Furthermore, claim 1 recites "... concatenating said routing table data 
received in step (a) with the contents of the routing table data stored by said 
given portal." This limitation relates to the combining of routing table data in a 
given portal. Nowhere does Tai disclose or suggest the feature of combining 
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routing table data by concatenation in a given portal. The portion of Tai cited by 
the examiner as disclosing this feature, namely Column 1 , page 1669, in fact 
teaches intersecting lists to obtain a list of stations ids on all ports that are 
directly connected to that LAN. Applicants submit that intersecting lists to obtain 
a list of station ids is different from concatenating routing table data, and that Tai 
simply does not mention or suggest the concatenation of table data as recited in 
claim 1 . Therefore, applicants submit that Tai also fails to disclose or suggest at 
least this limitation of claim 1 . 

Moreover, claim 1 recites "... repeating the above steps by said given 
portal until routing data concerning all buses in the network has been received by 
said given portal." This provides that steps (a), (b), (c) and (d) are executed 
iteratively until a stop condition is present. A stop condition being that the routing 
table data concerning all buses has been received. This step is also not 
disclosed or suggested in Tai. 

The Examiner cites page 1668, column 2, paragraph 3.1 of Tai as 
disclosing this step. This paragraph, however, provides "by periodically 
exchanging the concatenated ids among brouters attached to the same LAN, the 
up to date LAN id is determined and the master brouter is elected." This 
passage means that a process of electing the minimum id as the LAN id is 
conducted periodically to adapt to changes in the network, for example, for 
brouter failure. This passage has nothing to do with conducting an iterative 
process of building a routing table until a stop condition exists. Therefore, 
applicants submit that Tai does not disclose or suggest the iteration feature as 
recited in step (e) of claim 1 . 

In summary, Tai teaches a system that builds delay tables, exchanges the 
delay tables and computes the routing tables from the delay tables. This process 
is completely different from the method of the present invention, which involves 
exchanging routing tables and concatenating the exchanged routing tables in an 
iterative process to generate the routing tables. Applicants further submit that 
even in view of the examiner's response in the outstanding office action, the 
present claims are not anticipated by Tai because Tai fails to disclose or suggest 
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each and every limitation of claim 1 as discussed above. Claims 2-4, 7-10 and 
12-13, which depend from claim 1 are believed to be not anticipated by Tai for at 
least the same reasons as those applied to claim 1 . Independent claim 14 
recites the features of independent claim 1 in apparatus form, and as such, 
applicants submit that claim 14 is not anticipated by Tai for at least the same 
reasons as those discussed above. 

Rejection of claims 5 and 6 under 35 USC §1 03(a) as being unpatentable 
over Tai and further in view of Garcia (US Published Application 
20020049561) 

Garcia is cited as teaching that the routing table data transmitted or 
broadcast by a given portal contains the entire routing table. 

However, even assuming arguendo that Garcia teaches the above, 
applicants submit that the alleged teachings still fail to cure the defect of Tai as 
applied to claim 1 as discussed above. Thus, applicants submit that claims 5 
and 6, which depend from claim 1 , are patentably distinguishable over the 
combination of Tai and Garcia. 

Rejection of claim 11 under 35 USC §1 03(a) as being unpatentable over Tai 
and further in view of Oechsle (US Pat. No. 5570466) 

Oechsle is cited as teaching selecting the path to a given remote bus as a 
function of the bandwidth of portals on the path. 

However, even assuming arguendo that Oechsle teaches the above, 
applicants submit that the alleged teachings of Oechsle still fail to cure the defect 
of Tai as applied to claim 1 as discussed above. Thus, applicants submit that 
claim 1 1 , which depends from claim 1 , is patentably distinguishable over the 
combination of Tai and Oechsle. 
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* 



Having fully addressed the Examiner's rejections it is believed that, in view 
of the preceding amendments and remarks, this application stands in condition 
for allowance. Accordingly then, entry of this amendment, reconsideration, 
withdrawal of the final rejection and allowance of all claims are respectfully 
solicited. If, however, the Examiner is of the opinion that such action cannot be 
taken, the Examiner is invited to contact the applicant's attorney at (609) 734- 
6815, so that a mutually convenient date and time for a telephonic interview may 
be scheduled. 



I hereby certify that this amendment is being deposited with the United States Postal Service as First Class 
Mail, postage prepaid, in an envelope addressed to Mail Stop AF, Commissioner for Patents, Alexandria, Virginia, 
223I3-I450on: 




Respectfully submitted, 
Y. Legallais, et al. 



By: Paul P. Kiel 

Attorney for Applicants 
Registration No. 40,677 



THOMSON Licensing Inc. 

Two Independence Way, Suite 200 

Princeton, NJ 08540 
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